<!DOCTYPE html>
<html lang="en">

<head>
    <meta charset="UTF-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>评论-马丁福勒的网站-敏捷软件开发</title>

    <link rel="stylesheet" href="/collection/martinfowler/agile.css">
</head>
<!-- 这个是首页 -->

<body>

    <!-- 页面头部 -->
    <header id="banner"
        style="background-image: url('/collection/martinfowler/img/poetta.png'); background-repeat: no-repeat">
        <div class="name-logo">
            <a href="https://martinfowler.com">
                <img src="/collection/martinfowler/mf-name-white.png">
            </a>
        </div>
        <div class="searach">
            <form method="GET" action="https://www.google.com/search">
                <input type="hidden" name="ie" value="UTF-8">
                <input type="hidden" name="oe" value="UTF-8">
                <input class="field" type="text" name="q" size="15" maxlength="255" value="">
                <button class="button" type="submit" name="btnG" value=" " title="Search">
                    <input type="hidden" name="domains" value="martinfowler.com">
                    <input type="hidden" name="sitesearch" value="">
                    <input type="hidden" name="sitesearch" value="martinfowler.com">
                </button>
            </form>
        </div>
        <div class="menu-button navmenu-button">
            <a class="icon icon-bars" href="#navmenu-bottom"></a>
        </div>
        <nav class="top-menu">
            <ul>
                <li><a class="" href="https://refactoring.com">
                        <!-- Refactoring --> 重构
                    </a></li>

                <li><a class="" href="./agile.html">
                        <!-- Agile --> 敏捷
                    </a></li>

                <li><a class="" href="./architecture">
                        <!-- Architecture --> 架构
                    </a></li>

                <li><a class="" href="./aboutMe.html">
                        <!-- About --> 关于martinfowler
                    </a></li>

                <li><a class="tw" href="https://www.thoughtworks.com">ThoughtWorks</a></li>

                <li><a class="icon icon-rss" href="./feed.atom" title="feed"></a></li>

                <li><a class="icon icon-twitter" href="https://www.twitter.com/martinfowler" title="twitter stream"></a>
                </li>
            </ul>
        </nav>
    </header>

    <nav id="top-navmenu" style="display: none;">
        <nav class="navmenu">
            <div class="nav-head">
                <div class="search">
                    <!-- SiteSearch Google -->
                    <form method="GET" action="https://www.google.com/search">
                        <input type="hidden" name="ie" value="UTF-8">
                        <input type="hidden" name="oe" value="UTF-8">
                        <input class="field" type="text" name="q" size="15" maxlength="255" value="">
                        <button class="button" type="submit" name="btnG" value=" " title="Search">
                            <input type="hidden" name="domains" value="martinfowler.com">
                            <input type="hidden" name="sitesearch" value="">
                            <input type="hidden" name="sitesearch" value="martinfowler.com">

                        </button>
                    </form>
                </div>

                <div class="closediv">
                    <span class="close" title="close"></span>
                </div>
            </div>

            <div class="nav-body">
                <div class="topics">
                    <h2>Topics</h2>

                    <p><a href="/collection/architecture">
                            <!-- Architecture --> 架构
                        </a></p>

                    <p><a href="https://refactoring.com">
                            <!-- Refactoring --> 重构
                        </a></p>

                    <p><a href="/collection/agile.html">
                            <!-- Agile --> 敏捷
                        </a></p>

                    <p><a href="/collection/delivery.html">
                            <!-- Delivery --> 交付
                        </a></p>

                    <p><a href="/collection/microservices">
                            <!-- Microservices --> 微服务
                        </a></p>

                    <p><a href="/collection/data">
                            <!-- Data --> 数据
                        </a></p>

                    <p><a href="/collection/testing">
                            <!-- Testing --> 测试
                        </a></p>

                    <p><a href="/collection/dsl.html">
                            <!-- DSL --> 领域特定语言
                        </a></p>
                </div>

                <div class="about">
                    <h2>about me</h2>

                    <p><a href="/collection/aboutMe.html">About</a></p>

                    <p><a href="/collection/books">Books</a></p>

                    <p><a href="/collection/faq.html">FAQ</a></p>
                </div>

                <div class="content">
                    <h2>content</h2>

                    <p><a href="/collection/videos.html">Videos</a></p>

                    <p><a href="/collection/tags">Content Index</a></p>

                    <p><a href="/collection/articles/eurogames">Board Games</a></p>

                    <p><a href="/collection/photos">Photography</a></p>
                </div>

                <div class="tw">
                    <h2>ThoughtWorks</h2>

                    <p><a href="https://thoughtworks.com/insights">Insights</a></p>

                    <p><a href="https://thoughtworks.com/careers">Careers</a></p>

                    <p><a href="https://thoughtworks.com/products">Products</a></p>
                </div>

                <div class="feeds">
                    <h2>follow</h2>

                    <p><a href="https://www.twitter.com/martinfowler">Twitter</a></p>

                    <p><a href="/collection/feed.atom">RSS</a></p>
                </div>
            </div>
        </nav>
    </nav>

    <!-- 网页主体 -->
    <main>
        <!-- <h1>Agile Software Guide</h1> -->
        <h1>敏捷软件指南</h1>

        <section class="lede">
            <section class="main">
                <p>In the last decade agile software development has moved from being a cult
                    technique to an increasing part of the mainstream. I was lucky enough to be
                    at the beginning of this story, with early experiences on the 'birth
                    project' of <a href="/bliki/ExtremeProgramming.html">Extreme Programming</a> and a co-author of
                    the <a href="http://agileManifesto.org">Manifesto for Agile Software
                        Development</a>. ThoughtWorks started using agile techniques in 2000 and
                    we've since successfully used them on our projects world-wide. We've learned
                    a huge amount about using agile methods in enterprise settings and are
                    committed to sharing this learning to help foster their intelligent
                    adoption.</p>
                <p>十年来敏捷软件开发从小众成为行业主流。作者从见证了这个过程，作为<a href="/bliki/ExtremeProgramming.html">极限编程</a>发起人，作为
                    <a href="http://agileManifesto.org">敏捷软件开发宣言</a>的作者之一。ThoughtWorks 从2000年开始使用敏捷技术，并且成功推广到他们的全球范围的项目。
                    他们有大量的敏捷方法实践， 并且贡献给有兴趣的其他人。
                </p>
            </section>

            <section class="side">
                <p class="explain">A guide to material on martinfowler.com about
                    agile software development.</p>

                <div class="author"><a href="/"><img alt="Photo of Martin Fowler" src="/mf.jpg" width="80"></a>
                    <p class="name"><a href="/">Martin Fowler</a></p>
                </div>

                <p class="date">
                    <time datetime="2019-08-01">1 Aug 2019</time>
                </p>
            </section>
        </section>

        <section class="essence synopsis" id="TheEssenceOfAgileSoftwareDevelopment">
            <!-- <h2>The Essence of Agile Software Development</h2> -->
            <h2>敏捷软件开发的本质</h2>

            <p>It's been over a decade since the developers of agile methods first
                started to talk about their approaches. In this time agile thinking has
                changed from a niche activity to an approach that is widely used. However,
                like any popular technique, agile software development has suffered from
                <a href="/bliki/SemanticDiffusion.html">semantic diffusion</a>, so much of what we
                see under the name of agile doesn't bear much resemblance to what the early
                pioneers were doing. So I think it's important to revisit the essential
                elements of agile thinking.
            </p>

            <p>敏捷软件开发诞生已经十多年了。敏捷思想从少数人传播到大多数人。和其它受欢迎的技术一样，敏捷软件开发也遇到了
                <a href="/bliki/SemanticDiffusion.html">semantic diffusion</a>，人们讨论的敏捷软件开发已经偏离了本意。
                作者认为重识敏捷思想的本质很重要。
            </p>

            <p>I've always seen the essence of agile thinking resting on two
                contrasts with traditional plan-driven software engineering: </p>
            
            <p>作者经常看到敏捷思想和传统计划驱动的软件工程的两个差异：</p>
        </section>

        <section class="def">
            <p class="left"><i>Agile</i> Development<br/><i>敏捷</i> 开发</p>

            <ul class="right">
                <li>is <i>adaptive</i> rather than predictive</li>
                <li>是 <i>适应的</i> 而不是预先计划的</li>

                <li>is <i>people-oriented</i> rather than process-oriented</li>
                <li>是 <i>面向人的</i> 而不是面向进度的</li>
            </ul>
        </section>

        <section class="contrasts">
            <p><b>Plan-driven</b> engineering expects us to come up with a <b>predictive plan</b>
                that precedes development. The plan lays out the people, resources and
                timelines for the overall project. Software design is also done up-front,
                with implementation expected to conform with this design. <b>Success</b> is
                measured according to <b>how well development follows this plan</b>.</p>
            
            <p><b>计划驱动</b> 工程期望人符合一个预先的 <b>对未来的计划</b>. 这种计划安排了整个项目的人员，资源和时间. 
                软件的设计也是预先做好的, 要求设计得到实现. <b>成功</b> 取决于 <b>开发如何按照计划执行</b>.</p>

            <p><b>Agile</b> plans are a baseline that we use to help us control changes. Agile
                teams plan just as carefully as traditional teams, but the <b>plans are
                    constantly revising</b> to reflect the things we learn during a project. <b>Success</b>
                is based on <b>value delivered</b> by the software.</p>

            <p><b>敏捷</b> 的计划是我们用于控制变化的基线. 敏捷团队的计划和传统团队的计划一样谨慎, 只是 
                <b>计划总是不断改变</b> 来适应人们对项目的理解的变化. 
                <b>成功</b>
                基于软件 <b>交付的价值</b>.</p>    

            <p><b>Plan-driven</b> engineering seeks a process which provides enough structure
                to <b>reduce individual variations</b> to insignificance. Such an industrial
                process is more predictable, copes better when people transfer, and is
                easier to define skills and career paths.</p>
        
            <p><b>计划驱动的</b> 工程寻找一个过程能提供足够的结构来 <b>减少特殊的变动</b> 变成没有影响的. 这
                样的工业过程是可以预测的, 要求人和职业技能是可以简单定义的.</p>

            <p><b>Agile</b> engineering sees software development as a <b>primarily human
                    activity</b>, where the people involved and how they bond as a team are the
                primary driver behind success. Processes (and tools) can enhance a team's
                effectiveness, but are always second-order influences.</p>

                
            <p><b>敏捷</b> 工程将软件开发看作 <b>主要是人的活动</b>, 人是复杂的 以及 人们如何组成团队 是成功的主要因素. 
                流程和工具可以提高团队的效率, 但都只能算次要的因素.</p>

        </section>

        <section class="card-box">
            <div class="article-card">
                <!-- <h3><a href="/articles/newMethodology.html">The New Methodology</a></h3> -->
                <h3><a href="/articles/newMethodology.html">新方法</a></h3>

                <div class="card-body">
                    <p class="card-image"><img src=""></p>

                    <p class="abstract">After my positive experiences with Extreme Programming in the
                        90s, I became curious about similar sounding approaches such as Scrum,
                        Crystal, and DSDM. Digging into them, I distilled the common
                        characteristics of these new methodologies: preferring adaptive planning
                        to predictive planning, and treating people as more important to success
                        than what process was used. In time these approaches gathered under the
                        banner of agile software development, (and I revised the article) but I
                        still find the perspective in this article a good way to understand the
                        essence of agility.</p>
                    
                    <p class="abstract">作者在90年代有了极限编程的成功经验后, 开始对其它类似的行为感到好奇比如 Scrum,
                        Crystal, 和 DSDM. 深入了解这些, 作者把这些方法论的相同特征提取出来: 适应性的计划比预测性的计划更好, 
                        成功的因素中人的作用比过程的作用更大. 这些作用在敏捷软件开发中显现出来, (作者改进了本文章) 但是作者还是提出了
                        一个很好的方法来理解敏捷的本质.</p>

                    <div class="meta">
                        <p class="credits">by Martin Fowler</p>

                        <p class="date">13 Dec 2005</p>

                        <p class="more"><a href="/articles/newMethodology.html">来读这篇文章…</a></p>

                        <p class="type article">article</p>

                        <p class="tags"> <span class="tag-link"><a href="/tags/agile.html">agile</a></span> <span
                                class="tag-link"><a href="/tags/process%20theory.html">process theory</a></span> </p>
                    </div>
                </div>
            </div>

            <div class="article-card">
                <!-- <h3><a href="https://agilemanifesto.org">Manifesto for Agile Software Development</a></h3> -->
                <h3><a href="https://agilemanifesto.org">敏捷软件开发宣言</a></h3>

                <div class="card-body">
                    <p class="card-image"><img src="./img/agile/agileManifestoBackground.jpg"></p>

                    <p class="abstract">It may not have started it all, but the manifesto gave
                        the movement a name together with a dollop of initial energy. A decade later
                        it still captures the essence of what agile methods are about.</p>

                    <p class="abstract">这可能并未表达出全部, 但是宣言将行动最初的精神赋予了一个名字. 
                        十年来其始终体现了敏捷方法的本质.</p>

                    <div class="meta">
                        <!-- <p class="credits">by 17 authors</p> -->
                        <p class="credits">有 17 个作者</p>

                        <p class="more"><a href="https://agilemanifesto.org">看一下敏捷软件开发宣言</a></p>

                        <p class="tags"> <span class="tag-link"><a href="/tags/agile.html">agile</a></span> </p>
                    </div>
                </div>
            </div>

            <div class="article-card">
                <!-- <h3><a href="/videos.html#agile-essence-fluency">Talk: Agile Essence and Fluency</a></h3> -->
                <h3><a href="/videos.html#agile-essence-fluency">谈话: 敏捷本质和答辩</a></h3>

                <div class="card-body">
                    <p class="card-image"><img src="./img/video/xconf-hands-up.png"></p>

                    <p class="abstract">
                    </p>
                    <p>It's been over a decade since we wrote the Manifesto for
                        Agile Software Development, and the agile meme has been more
                        successful than we ever could have hoped for. But like any
                        success, there is the regular danger of Semantic Diffusion. I
                        try to combat this disease by describing the essence of agile
                        software development: preferring adaptive planning to predictive
                        planning and favoring people over process.</p>
                    
                    <p>从写敏捷软件开发宣言距今已经十多年了, 敏捷的文化已经非常成功. 就像其它成功一样，存在语义偏差的危险. I
                        要不断阐明敏捷的本质来对抗这种危险: 适应性的计划比预测性的计划更好，人比过程更重要.</p>

                    <p>I then describe the Agile Fluency model, which I find an
                        effective way to think about how agile teams become proficient,
                        and the steps you typically go through as you become a more
                        skillful user of agile techniques.</p>

                    <p>作者之后描绘了敏捷答辩模型, 就是作者考虑找到的有效的方法来让敏捷团队更成熟,
                        当你更熟练掌握敏捷技术，你将经历的事情.</p>
                        
                    <p></p>

                    <div class="meta">
                        <p class="date">2019</p>

                        <p class="more"><a href="/videos.html#agile-essence-fluency">来看看这个方法</a></p>

                        <p class="type video">video</p>

                        <p class="length">24 minutes</p>

                        <p class="tags"> </p>
                    </div>
                </div>
            </div>
        </section>

        <section class="fluency">
            <div class="article-card">
                <!-- <h3><a href="/articles/agileFluency.html">The Agile Fluency Model</a></h3> -->
                <h3><a href="/articles/agileFluency.html">敏捷辩论模型</a></h3>

                <div class="card-body">
                    <p class="card-image"><img
                            src="https://martinfowler.com/articles/agileFluency/agile-fluency-model-v2-simple-2-1.png">
                    </p>

                    <p class="abstract">
                        Agile methods are solidly in the mainstream, but that popularity hasn't been without its
                        problems. Organizational leaders are complaining that they’re not getting the benefits they
                        expected. This article presents a fluency model that will help you get the most out of agile
                        ideas. Fluency evolves through four distinct zones, each with its own benefits, required
                        proficiencies, and key metrics.
                    </p>

                    <p class="abstract">
                        敏捷方法是当前主流, 但是这种收欢迎也有其问题. 
                        组织机构的领导者抱怨没有得到他们期望的效益. 这篇文章提供了一个答辩的模型让你能够充分领会敏捷的观点. 
                        辩论在四个独立的方面改进, , 需要的精通和关键metrics.
                    </p>

                    <div class="meta">
                        <p class="credits">by James Shore and Diana Larsen</p>

                        <p class="date">6 Mar 2018</p>

                        <p class="more"><a href="/articles/agileFluency.html">Read more…</a></p>

                        <p class="type article">article</p>

                        <p class="tags"> <span class="tag-link"><a href="/tags/agile.html">agile</a></span> <span
                                class="tag-link"><a href="/tags/process%20theory.html">process theory</a></span> </p>
                    </div>
                </div>
            </div>
        </section>

        <hr class="sep">

        <section class="synopsis tech" id="TechnicalPractices">
            <!-- <h2>Technical Practices</h2> -->
            <h2>技术练习</h2>

            <p>To make agile work, you need solid technical practices. A lot of agile
                education under-emphasizes these, but if you skimp on this you won't gain
                the productivity and responsiveness benefits that agile development can give
                you (stranding you in the first zone of <a href="/articles/agileFluency.html">agile
                    fluency</a>). This is one of the reasons that I still think that <a
                    href="/bliki/ExtremeProgramming.html">Extreme Programming</a> is the most valuable of the named
                agile
                methods as a core and starting point. </p>
            
            <p>要让敏捷起作用k, 你需要坚实的技术基础. 大量的敏捷教程都在强调这点, 但是如果你缺少这些，你就无法得到敏捷的好处
                 (在第一个方面就会搁浅 <a href="/articles/agileFluency.html">敏捷辩论</a>). 所以我一直认为 <a
                    href="/bliki/ExtremeProgramming.html">极限编程</a> 是最有价值的敏捷方法和核心出发点. </p>
        </section>

        <section class="card-box">
            <div class="article-card refact">
                <!-- <h3><a href="https://refactoring.com">Refactoring Guide</a></h3> -->
                <h3><a href="https://refactoring.com">重构指南</a></h3>

                <div class="card-body">
                    <p class="card-image"><img src="http://refactoring.com/refactoring-logo.png"></p>

                    <p class="abstract">Refactoring is a disciplined technique for restructuring an existing
                        body of code, altering its internal structure without changing its external
                        behavior.

                        Its heart is a series of small behavior preserving transformations. Each
                        transformation (called a "refactoring") does little, but a sequence of these
                        transformations can produce a significant restructuring. Since each
                        refactoring is small, it's less likely to go wrong. The system is kept fully
                        working after each refactoring, reducing the chances that a system can get
                        seriously broken during the restructuring.</p>
                    

                    <p class="abstract">重构是一个重新组织代码的技术, 改变代码的内部结构而不改变其外部表现.

                        重构的核心是一系列小的转换. 每个转换 (一个 "重构") 都是很小的, 但是一系列这种小的转换提供了有效的重构. 
                        因为每个重构都很小, 就不太容易出错. 在每次重构后系统保持完整运行, 减低系统在重构中出现验证错误的几率.</p>

                    <div class="meta">
                        <p class="credits">by Martin Fowler</p>

                        <p class="more"><a href="https://refactoring.com">来看重构</a></p>

                        <p class="type guide">guide</p>

                        <p class="tags"> <span class="tag-link"><a href="/tags/programming%20style.html">programming
                                    style</a></span> <span class="tag-link"><a
                                    href="/tags/extreme%20programming.html">extreme programming</a></span> <span
                                class="tag-link"><a href="/tags/refactoring.html">refactoring</a></span> </p>
                        
                        <p class="tags"> <span class="tag-link"><a href="/tags/programming%20style.html">编程风格
                                </a></span> <span class="tag-link"><a
                                href="/tags/extreme%20programming.html">极限编程</a></span> <span
                            class="tag-link"><a href="/tags/refactoring.html">重构</a></span> </p>
                    </div>
                </div>
            </div>

            <div class="article-card">
                <!-- <h3><a href="/articles/is-quality-worth-cost.html">Is High Quality Software Worth the Cost?</a></h3> -->
                <h3><a href="/articles/is-quality-worth-cost.html">高质量的软件是否值得付出?</a></h3>

                <div class="card-body">
                    <p class="card-image"><img src="https://martinfowler.com/articles/is-quality-worth-cost/card.png">
                    </p>

                    <p class="abstract">
                        A common debate in software development projects is between spending time
                        on improving the quality of the software versus concentrating on releasing
                        more valuable features. Usually the pressure to deliver functionality
                        dominates the discussion, leading many developers to complain that they
                        don't have time to work on architecture and code quality. This debate is
                        based on the assumption that increasing quality also increases costs, which
                        is our common experience. But the counter-intuitive reality is that internal
                        software quality removes the cruft that slows down developing new features,
                        thus decreasing the cost of enhancing the software.
                    </p>

                    <p class="abstract">
                        软件项目中经常看到这样的辩论， 时间用来提高软件的质量还是将时间用于提供更多的功能. 
                        通常交付更多功能的观点占据上分, 导致开发人员抱怨没有时间进行架构和代码质量的改进. 
                        这中辩论是基于改进质量会增加花费的假设, 这似乎是我们的常识. 
                        但是事实是提高软件质量同事也清除了开发新功能的阻碍,
                        因此降低了对软件新增的投入.
                    </p>

                    <div class="meta">
                        <p class="credits">by Martin Fowler</p>

                        <p class="date">29 May 2019</p>

                        <p class="more"><a href="/articles/is-quality-worth-cost.html">来看看吧…</a></p>

                        <p class="type article">article</p>

                        <p class="tags"> <span class="tag-link"><a href="/tags/programming%20style.html">programming
                                    style</a></span> <span class="tag-link"><a
                                    href="/tags/productivity.html">productivity</a></span> <span class="tag-link"><a
                                    href="/tags/project%20planning.html">project planning</a></span> <span
                                class="tag-link"><a href="/tags/technical%20debt.html">technical debt</a></span> </p>
                    </div>
                </div>
            </div>

            <div class="article-card">
                <!-- <h3><a href="/delivery.html">Continuous Delivery Guide</a></h3> -->
                <h3><a href="/delivery.html">持续交付指南</a></h3>

                <div class="card-body">
                    <p class="abstract">It’s hard enough for software developers to write code that works on
                        their machine. But even when that’s done, there’s a long journey from there to
                        software that’s producing value - since software only produces value when it’s
                        in production. he essence of my philosophy to software delivery is to build
                        software so that it is always in a state where it could be put into
                        production. We call this Continuous Delivery because we are continuously
                        running a deployment pipeline that tests if this software is in a state to be
                        delivered.</p>

                    <p class="abstract">开发者在写出自己的机器上运行的代码已经足够难了. 
                        但是即使完成了这个任务，也只是软件产生价值的起点 - 软件要到生产环境上运行才产生价值. 
                        作者的软件交付的观点的本质是构建的软件随时可以放到生产环境上运行. 
                        之所以称为持续交付，因为我们总是在测试软件是否处于可以部署到生产环境的状态.</p>

                    <div class="meta">
                        <p class="credits">by Martin Fowler</p>

                        <p class="more"><a href="/delivery.html">持续交付..</a></p>

                        <p class="type guide">guide</p>

                        <p class="tags"> <span class="tag-link"><a href="/tags/continuous%20delivery.html">continuous
                                    delivery</a></span> </p>
                    </div>
                </div>
            </div>

            <div class="article-card self-test">
                <!-- <h3><a href="/bliki/SelfTestingCode.html">Self Testing Code</a></h3> -->
                <h3><a href="/bliki/SelfTestingCode.html">自测试的代码</a></h3>

                <div class="card-body">
                    <p class="card-image"><img src="https://martinfowler.com/bliki/images/selfTestingCode/sketch.png">
                    </p>

                    <p>Self-Testing Code is the name I used in <a href="/books/refactoring.html">Refactoring</a> to
                        refer to the practice
                        of writing comprehensive automated tests in conjunction with the
                        functional software. When done well this allows you to invoke a
                        single command that executes the tests - and you are confident that
                        these tests will illuminate any bugs hiding in your code.</p>
                    
                    <p>自测试代码是作者在 <a href="/books/refactoring.html">重构</a> 提出的编写可理解的自动化测试实践.
                        做到这点你可以执行一个命令执行测试 - 并且你有把握测试能够找到代码中的bug.</p>

                    <div class="meta">
                        <p class="credits">by Martin Fowler</p>

                        <p class="date">1 May 2014</p>

                        <p class="more"><a href="/bliki/SelfTestingCode.html">读一读测试…</a></p>

                        <p class="type bliki">bliki</p>

                        <p class="tags"> <span class="tag-link"><a href="/tags/agile.html">agile</a></span> <span
                                class="tag-link"><a href="/tags/continuous%20delivery.html">continuous
                                    delivery</a></span> <span class="tag-link"><a
                                    href="/tags/testing.html">testing</a></span> <span class="tag-link"><a
                                    href="/tags/extreme%20programming.html">extreme programming</a></span> <span
                                class="tag-link"><a href="/tags/programming%20style.html">programming style</a></span>
                            <span class="tag-link"><a href="/tags/refactoring.html">refactoring</a></span> </p>
                    </div>
                </div>
            </div>

            <div class="article-card">
                <!-- <h3><a href="/articles/designDead.html">Is Design Dead?</a></h3> -->
                <h3><a href="/articles/designDead.html">设计还有用吗?</a></h3>

                <div class="card-body">
                    <p class="card-image"><img src=""></p>

                    <p class="abstract">
                        For many that come briefly into contact with Extreme Programming,
                        it seems that XP calls for the death of software design. Not just is
                        much design activity ridiculed as "Big Up Front Design", but such
                        design techniques as the UML, flexible frameworks, and even
                        patterns are de-emphasized or downright ignored. In fact XP
                        involves a lot of design, but does it in a different way than
                        established software processes. XP has rejuvenated the notion of
                        evolutionary design with practices that allow evolution to become a
                        viable design strategy. It also provides new challenges and skills as
                        designers need to learn how to do a simple design, how to use
                        refactoring to keep a design clean, and how to use patterns in an
                        evolutionary style.
                    </p>

                    <p class="abstract">
                        短暂接触极限编程的人常常认为极限编程宣告了软件设计的死亡. 不仅仅是
                        很多设计活动被戏称为 "大统一设计", 以及UML，适应性框架等设计技术, 
                        甚至设计模式都被过分忽略. 事实上极限编程中使用到大量的设计, 只是和原来的设计方式不同了. 
                        极限变成有进化的设计的理念. 同时有新的挑战要求设计者有相应的技能，需要学会如何简单设计, 如何使用重构使设计保持干净,
                        并且如何使用设计模式保持进化的风格.
                    </p>

                    <div class="meta">
                        <p class="credits">by Martin Fowler</p>

                        <p class="date">May 2004</p>

                        <p class="more"><a href="/articles/designDead.html">看看吧…</a></p>

                        <p class="type article">article</p>

                        <p class="tags"> <span class="tag-link"><a href="/tags/popular.html">popular</a></span> <span
                                class="tag-link"><a href="/tags/design.html">design</a></span> <span class="tag-link"><a
                                    href="/tags/agile.html">agile</a></span> <span class="tag-link"><a
                                    href="/tags/extreme%20programming.html">extreme programming</a></span> <span
                                class="tag-link"><a href="/tags/evolutionary%20design.html">evolutionary
                                    design</a></span> </p>
                    </div>
                </div>
            </div>

            <div class="article-card">
                <!-- <h3><a href="/bliki/CodeAsDocumentation.html">Code As Documentation</a></h3> -->
                <h3><a href="/bliki/CodeAsDocumentation.html">代码既是文档</a></h3>

                <div class="card-body">
                    <p class="card-image"><img src=""></p>

                    <p>One of the common elements of agile methods is that they raise
                        programming to a central role in software
                        development - one much greater than the software engineering
                        community usually does. Part of this is classifying the code as a
                        major, if not the primary documentation of a software system.</p>

                    <p>敏捷方法都有个共同点就是将编程做为软件开发的中心角色. 其中一个表现是代码做为软件系统中的重要文档.</p>

                    <div class="meta">
                        <p class="credits">by Martin Fowler</p>

                        <p class="date">22 Mar 2005</p>

                        <p class="more"><a href="/bliki/CodeAsDocumentation.html">看看…</a></p>

                        <p class="type bliki">bliki</p>

                        <p class="tags"> <span class="tag-link"><a href="/tags/agile.html">agile</a></span> <span
                                class="tag-link"><a href="/tags/documentation.html">documentation</a></span> </p>
                    </div>
                </div>
            </div>
        </section>

        <hr class="sep">

        <section class="synopsis collaboration" id="Collaboration">
            <!-- <h2>Collaboration</h2> -->
            <h2>合作</h2>

            <p>Improving human collaboration is at the heart of agile thinking.
                Communication and feedback are two of the stated values of Extreme
                Programming, and agilists look to find ways to maximise these as part of
                their projects</p>
            
            <p>敏捷思想的核心是提高人们的合作.
                交流和反馈是极限编程的两个核心价值观</p>

        </section>

        <section class="card-box">
            <div class="article-card">
                <!-- <h3><a href="/articles/itsNotJustStandingUp.html">It's Not Just Standing Up: Patterns for Daily Standup
                        Meetings</a></h3> -->
        
                <h3><a href="/articles/itsNotJustStandingUp.html">不只是站立会: 每日站立会的模式</a></h3>

                <div class="card-body">
                    <p class="card-image"><img
                            src="https://martinfowler.com/articles/itsNotJustStandingUp/standingup.jpg"></p>

                    <p class="abstract">Daily stand-up meetings have become a common ritual of many teams, especially in
                        Agile software development. However, there are many subtle details that distinguish effective
                        stand-ups and a waste of time.</p>
                    
                    <p class="abstract">站立会已经变成了许多团队的每日仪式, 特别是在敏捷软件开发中. 
                        但是有许多不显眼的细节区分有价值的站立会和浪费时间的站立会.</p>


                    <div class="meta">
                        <p class="credits">by Jason Yip</p>

                        <p class="date">21 Feb 2016</p>

                        <p class="more"><a href="/articles/itsNotJustStandingUp.html">看看</a></p>

                        <p class="type article">article</p>

                        <p class="tags"> <span class="tag-link"><a href="/tags/agile.html">agile</a></span> </p>
                    </div>
                </div>
            </div>

            <div class="article-card">
                <!-- <h3><a href="/articles/on-pair-programming.html">On Pair Programming</a></h3> -->
                <h3><a href="/articles/on-pair-programming.html">论结对编程</a></h3>

                <div class="card-body">
                    <p class="card-image"><img src="https://martinfowler.com/articles/on-pair-programming/card.jpg"></p>

                    <p class="abstract">Many people who work in software development today have heard of the practice of
                        pair programming, yet it still only has patchy adoption in the industry.
                        One reason for its varying acceptance is that its benefits are not immediately
                        obvious, it pays off more in the medium- and long-term. And it's also not as
                        simple as "two people working at a single computer", so many dismiss it
                        quickly when it feels uncomfortable. However, in our experience, pair
                        programming is vital for collaborative teamwork and high quality
                        software.</p>
                    
                    <p class="abstract">许多开发人员听说过结对变成, 尽管现在还是很少.
                        结对编程不被接纳的一个原因是收益不能马上体现, 要到中期才有更多的回报- 还有长期. 并且他不是简单的 "两个人共用一台电脑", 
                        许多人马上感觉不舒服从而解散了. 然而, 依据作者的经验, 结对编程是对于团队合作和提高软件质量非常重要的.</p>

                    <div class="meta">
                        <p class="credits">by Birgitta Böckeler and Nina Siessegger</p>

                        <p class="date">15 Jan 2020</p>

                        <p class="more"><a href="/articles/on-pair-programming.html">看看…</a></p>

                        <p class="type article">article</p>

                        <p class="tags"> <span class="tag-link"><a href="/tags/extreme%20programming.html">extreme
                                    programming</a></span> <span class="tag-link"><a
                                    href="/tags/collaboration.html">collaboration</a></span> </p>
                    </div>
                </div>
            </div>

            <div class="article-card">
                <!-- <h3><a href="/bliki/UserStory.html">User Story</a></h3> -->
                <h3><a href="/bliki/UserStory.html">用户故事</a></h3>

                <div class="card-body">
                    <p class="card-image"><img src=""></p>

                    <p>User Stories are chunks of desired behavior of a software system.
                        They are widely used in agile software approaches to divide up a
                        large amount of functionality into smaller pieces for planning
                        purposes. You also hear the same concept referred to as a
                        <b>feature</b>, but the term "story" or "user story" has
                        become prevalent in agile circles these days.
                    </p>

                    <p>用户故事是软件系统期望行为的重要组成部分.
                        其在敏捷软件开发中广泛使用，将一大块功能分成小的计划目标. 你们也应该听说过
                        <b>feature</b>的概念, 只是 用户故事这个短语已经在敏捷界普遍使用了.
                    </p>

                    <div class="meta">
                        <p class="credits">by Martin Fowler</p>

                        <p class="date">22 Apr 2013</p>

                        <p class="more"><a href="/bliki/UserStory.html">看看…</a></p>

                        <p class="type bliki">bliki</p>

                        <p class="tags"> <span class="tag-link"><a href="/tags/agile.html">agile</a></span> <span
                                class="tag-link"><a href="/tags/requirements%20analysis.html">需求分析</a></span> </p>
                    </div>
                </div>
            </div>

            <div class="article-card">
                <!-- <h3><a href="/bliki/ConversationalStories.html">Conversational Stories</a></h3> -->
                <h3><a href="/bliki/ConversationalStories.html">会话故事</a></h3>

                <div class="card-body">
                    <p class="card-image"><img
                            src="https://martinfowler.com/bliki/images/conversationalStories/decreed.png"></p>

                    <p>Here's a common misconception about agile methods. It centers on
                        the way user stories are created and flow through the development
                        activity. The misconception is that the product owner (or business
                        analysts) creates user stories and then put them in front of
                        developers to implement. The notion is that this is a flow from
                        product owner to development, with the product owner responsible for
                        determining <i>what</i> needs to be done and the developers
                        <i>how</i> to do it.
                    </p>

                    <p>对敏捷方法有一个常见的误解. 开发活动集中在用户故事被创建. 
                        这个误解就是 产品经理 (或者说业务分析) 创建用户故事然后让开发者实现. 
                        产品经理到开发者是个流程, 产品经理决定 <i>什么</i> 需要实现，而开发只是
                        <i>如何</i> 实现.
                    </p>

                    <div class="meta">
                        <p class="credits">by Martin Fowler</p>

                        <p class="date">4 Feb 2010</p>

                        <p class="more"><a href="/bliki/ConversationalStories.html">看看…</a></p>

                        <p class="type bliki">bliki</p>

                        <p class="tags"> <span class="tag-link"><a href="/tags/agile.html">agile</a></span> <span
                                class="tag-link"><a href="/tags/extreme%20programming.html">extreme
                                    programming</a></span> <span class="tag-link"><a
                                    href="/tags/requirements%20analysis.html">requirements analysis</a></span> <span
                                class="tag-link"><a href="/tags/collaboration.html">collaboration</a></span> </p>
                    </div>
                </div>
            </div>

            <div class="article-card">
                <!-- <h3><a href="/bliki/FrequencyReducesDifficulty.html">Frequency Reduces Difficulty</a></h3> -->
                <h3><a href="/bliki/FrequencyReducesDifficulty.html">频率减低难度</a></h3>

                <div class="card-body">
                    <p class="card-image"><img
                            src="https://martinfowler.com/bliki/images/frequency-reduces-difficulty/graph.png"></p>

                    <p>One of my favorite soundbites is: <b>if it hurts, do it more
                            often</b>. It has the happy property of seeming nonsensical on the
                        surface, but yielding some valuable meaning when you dig deeper</p>

                    <p>作者最喜欢的一句名言是: <b>如果疼, 就经常做</b>. 虽然看起来这很可笑, 但深入了解后你会发现一些价值</p>

                    <div class="meta">
                        <p class="credits">by Martin Fowler</p>

                        <p class="date">28 Jul 2011</p>

                        <p class="more"><a href="/bliki/FrequencyReducesDifficulty.html">再看看吧…</a></p>

                        <p class="type bliki">bliki</p>

                        <p class="tags"> <span class="tag-link"><a href="/tags/agile.html">agile</a></span> <span
                                class="tag-link"><a href="/tags/continuous%20delivery.html">continuous
                                    delivery</a></span> <span class="tag-link"><a
                                    href="/tags/productivity.html">productivity</a></span> <span class="tag-link"><a
                                    href="/tags/process%20theory.html">process theory</a></span> </p>
                    </div>
                </div>
            </div>

            <div class="article-card">
                <!-- <h3><a href="/articles/useOfMetrics.html">An Appropriate Use of Metrics</a></h3> -->
                <h3><a href="/articles/useOfMetrics.html">适当使用指标</a></h3>

                <div class="card-body">
                    <p class="card-image"><img src=""></p>

                    <p class="abstract">
                        Management love their metrics. The thinking goes something
                        like this, "We need a number to measure how we’re doing.
                        Numbers focus people and help us measure success." Whilst
                        well intentioned, management by numbers unintuitively leads to
                        problematic behavior and ultimately detracts from broader
                        project and organizational goals. Metrics inherently aren’t a
                        bad thing; just often, inappropriately used. This essay
                        demonstrates many of the issues caused by management’s
                        traditional use of metrics and offers an alternative to
                        address these dysfunctions.
                    </p>

                    <p class="abstract">
                        管理者喜欢他们的指标. 这个想法就像是这样的, "我们需要一个数字表示做得怎么样了.
                        数字让人们专心，并且让我们成功." 尽管这个想法很好, 根据数字进行管理会
                        导致错误的行为并最终导致更广泛的目标受到损害.指标本身并非坏事; 只是往往被错误地使用. 
                        这篇短文收集了一些因此导致的问题.
                    </p>

                    <div class="meta">
                        <p class="credits">Patrick Kua</p>

                        <p class="date">19 Feb 2013</p>

                        <p class="more"><a href="/articles/useOfMetrics.html">来看这篇短文…</a></p>

                        <p class="type article">article</p>

                        <p class="tags"> <span class="tag-link"><a href="/tags/metrics.html">metrics</a></span> <span
                                class="tag-link"><a href="/tags/productivity.html">productivity</a></span> <span
                                class="tag-link"><a href="/tags/project%20planning.html">project planning</a></span>
                            <span class="tag-link"><a href="/tags/technical%20leadership.html">technical
                                    leadership</a></span> </p>
                    </div>
                </div>
            </div>

            <div class="article-card">
                <!-- <h3><a href="/articles/remote-or-co-located.html">Remote versus Co-located Work</a></h3> -->
                <h3><a href="/articles/remote-or-co-located.html">远程办公对比集中办公</a></h3>

                <div class="card-body">
                    <p class="card-image"><img src="https://martinfowler.com/articles/remote-or-co-located/card.png">
                    </p>

                    <p class="abstract">
                        There isn't a simple dichotomy of remote versus co-located work,
                        instead there are several patterns of distribution for teams each
                        of which has different trade-offs and effective techniques
                        suitable for them. While it's impossible to determine conclusive
                        evidence, my sense is that most groups are more productive working
                        in a co-located manner. But you can build a more productive team
                        by using a distributed working model, because it gives you access
                        to a wider talent pool.
                    </p>


                    <p class="abstract">
                        远程办公和集中不能简单对比,
                        分布式的团队有许多工作模式，各自都有不同的特点，使用不同的技术适应其特点. 
                        作者的观点是大多数情况下，集中办公的效率更高. 人们任然可以组建分布式的团队, 毕竟这样可以让更多人才加入.
                    </p>

                    <div class="meta">
                        <p class="credits">by Martin Fowler</p>

                        <p class="date">19 Oct 2015</p>

                        <p class="more"><a href="/articles/remote-or-co-located.html">Read more…</a></p>

                        <p class="type article">article</p>

                        <p class="tags"> <span class="tag-link"><a href="/tags/agile.html">agile</a></span> <span
                                class="tag-link"><a href="/tags/productivity.html">productivity</a></span> <span
                                class="tag-link"><a href="/tags/team%20environment.html">team environment</a></span>
                            <span class="tag-link"><a href="/tags/team%20organization.html">team organization</a></span>
                            <span class="tag-link"><a href="/tags/collaboration.html">collaboration</a></span> <span
                                class="tag-link"><a href="/tags/covid-19.html">covid-19</a></span> </p>
                    </div>
                </div>
            </div>

            <div class="article-card">
                <h3><a href="/articles/agileOffshore.html">Using an Agile Software Process with Offshore
                        Development</a></h3>

                <div class="card-body">
                    <p class="card-image"><img src=""></p>

                    <p class="abstract">For the last four years ThoughtWorks has operated a lab in
                        Bangalore India to support our software development projects in
                        North America and Europe. Traditional approaches to offshore
                        development are based on plan-driven methodologies, but we are very
                        firmly in the agile camp. Here I discuss our experiences and lessons
                        learned in doing offshore agile development. So far we've discovered
                        that we can make it work, although the benefits are still open to
                        debate. (Although this article was last updated in 2006, I our
                        visited our offshore work in 2011 and found the lessons to
                        still be relevant and thus the article did not need a further
                        significant revision.)</p>

                    <div class="meta">
                        <p class="credits">by Martin Fowler</p>

                        <p class="date">18 Jul 2006</p>

                        <p class="more"><a href="/articles/agileOffshore.html">Read more…</a></p>

                        <p class="type article">article</p>

                        <p class="tags"> <span class="tag-link"><a href="/tags/agile.html">agile</a></span> </p>
                    </div>
                </div>
            </div>

            <div class="article-card">
                <h3><a href="/bliki/CustomerAffinity.html">Customer Affinity</a></h3>

                <div class="card-body">
                    <p class="card-image"><img src=""></p>

                    <p>When someone is looking at what makes up a top-class enterprise
                        software developer, often the conversation may turn to knowledge of
                        frameworks and languages, or perhaps the ability to understand
                        complicated algorithms and data structures. For me, one of the most
                        important traits in a programmer, or indeed in a development team,
                        is something that I'll call Customer Affinity. This is the interest
                        and closeness that the developers have in the business problem that
                        the software is addressing, and in the people who live in that
                        business world.</p>

                    <div class="meta">
                        <p class="credits">by Martin Fowler</p>

                        <p class="date">28 Jul 2006</p>

                        <p class="more"><a href="/bliki/CustomerAffinity.html">Read more…</a></p>

                        <p class="type bliki">bliki</p>

                        <p class="tags"> <span class="tag-link"><a href="/tags/agile.html">agile</a></span> <span
                                class="tag-link"><a href="/tags/team%20organization.html">team organization</a></span>
                            <span class="tag-link"><a href="/tags/requirements%20analysis.html">requirements
                                    analysis</a></span> </p>
                    </div>
                </div>
            </div>

            <div class="article-card">
                <h3><a href="/bliki/OutcomeOriented.html">Outcome Oriented</a></h3>

                <div class="card-body">
                    <p class="card-image"><img
                            src="https://martinfowler.com/bliki/images/outcomeOriented/outcome-oriented.png"></p>

                    <p>People who sponsor development of software usually aren’t very interested in
                        development metrics such as velocity or frequency of deployment to production. They care
                        more about business benefits that the software will deliver such as lower manual effort,
                        better sales conversion, greater customer satisfaction, i.e business outcomes.
                        Outcome-oriented teams are those that are mandated and equipped to deliver business
                        outcomes, such teams have people with the capability to carry out all necessary
                        activities to realize the outcome.. By contrast, <a
                            href="/bliki/ActivityOriented.html">ActivityOriented</a> teams are neither
                        equipped nor mandated to do so. They can only perform one of several activities required
                        to realize an outcome.</p>

                    <div class="meta">
                        <p class="credits">by Sriram Narayan</p>

                        <p class="date">1 Jun 2016</p>

                        <p class="more"><a href="/bliki/OutcomeOriented.html">Read more…</a></p>

                        <p class="type bliki">bliki</p>

                        <p class="tags"> <span class="tag-link"><a href="/tags/agile%20adoption.html">agile
                                    adoption</a></span> <span class="tag-link"><a
                                    href="/tags/team%20organization.html">team organization</a></span> </p>
                    </div>
                </div>
            </div>
        </section>

        <hr class="sep">

        <section class="synopsis problems" id="Problems">
            <h2>Problems</h2>

            <p>While the agile mindset can help many teams deliver software more
                effectively, the world of agile software is far from free of problems. As
                with any popular approach semantic diffusion has set in, resulting in many
                things being done in the name of "agile" that have little to do with the
                ideas that motivated us to write the manifesto.</p>
        </section>

        <section class="card-box">
            <div class="article-card">
                <h3><a href="/articles/agile-aus-2018.html">The State of Agile Software in 2018</a></h3>

                <div class="card-body">
                    <p class="card-image"><img src="https://martinfowler.com/articles/agile-aus-2018/card.jpg"></p>

                    <p class="abstract">On the surface, the world of agile software development is bright,
                        since it is now mainstream. But the reality is troubling, because much of
                        what is done is faux-agile, disregarding agile's values and principles. The three
                        main challenges we should focus on are: fighting the Agile Industrial
                        Complex and its habit of imposing process upon teams, raising the importance
                        of technical excellence, and organizing our teams around products (rather than
                        projects). Despite the problems, the community's great strength is its ability
                        to learn and adapt, tackling problems that we original manifesto authors
                        didn't imagine.</p>

                    <div class="meta">
                        <p class="credits">by Martin Fowler</p>

                        <p class="date">25 Aug 2018</p>

                        <p class="more"><a href="/articles/agile-aus-2018.html">Read more…</a></p>

                        <p class="type article">article</p>

                        <p class="tags"> <span class="tag-link"><a href="/tags/agile.html">agile</a></span> <span
                                class="tag-link"><a href="/tags/talk%20videos.html">talk videos</a></span> </p>
                    </div>
                </div>
            </div>

            <div class="article-card">
                <h3><a href="/bliki/SemanticDiffusion.html">Semantic Diffusion</a></h3>

                <div class="card-body">
                    <p class="card-image"><img src=""></p>

                    <p>I have the habit of creating <a href="/bliki/Neologism.html">Neologism</a>s to describe
                        the things I see in software development. It's a common habit amongst
                        writers in this field, for software development still lacks much useful
                        jargon. One of the problems with building a jargon is that terms
                        are vulnerable to losing their meaning, in a process of
                        semantic diffusion - to use yet another potential addition to our
                        jargon.</p>

                    <div class="meta">
                        <p class="credits">by Martin Fowler</p>

                        <p class="date">14 Dec 2006</p>

                        <p class="more"><a href="/bliki/SemanticDiffusion.html">Read more…</a></p>

                        <p class="type bliki">bliki</p>

                        <p class="tags"> <span class="tag-link"><a href="/tags/agile%20adoption.html">agile
                                    adoption</a></span> </p>
                    </div>
                </div>
            </div>

            <div class="article-card">
                <h3><a href="/bliki/AgileImposition.html">Agile Imposition</a></h3>

                <div class="card-body">
                    <p class="card-image"><img src=""></p>

                    <p>According to the current board of the Agile Alliance, agile
                        methods <a href="http://www.infoq.com/articles/agile-alliance-survey-2006">have
                            "crossed the chasm" </a>, which I think means they are becoming more
                        widespread. While this has its advantages, it also brings
                        problems. As a methodology or design approach becomes fashionable,
                        then we see a lot people using it, or teaching it, who are focusing on
                        the fashion rather than the real details. This can lead to
                        reports of things done in agile's name which are a polar opposite to
                        the principles of movement's founders.</p>

                    <div class="meta">
                        <p class="credits">by Martin Fowler</p>

                        <p class="date">2 Oct 2006</p>

                        <p class="more"><a href="/bliki/AgileImposition.html">Read more…</a></p>

                        <p class="type bliki">bliki</p>

                        <p class="tags"> <span class="tag-link"><a href="/tags/agile.html">agile</a></span> <span
                                class="tag-link"><a href="/tags/agile%20adoption.html">agile adoption</a></span> </p>
                    </div>
                </div>
            </div>

            <div class="article-card">
                <h3><a href="/bliki/FlaccidScrum.html">Flaccid Scrum</a></h3>

                <div class="card-body">
                    <p class="card-image"><img src=""></p>

                    <p>There's a mess I've heard about with quite a few projects
                        recently. It works out like this:</p>

                    <ul>
                        <li>They want to use an agile process, and pick Scrum</li>

                        <li>They adopt the Scrum practices, and maybe even the principles</li>

                        <li>After a while progress is slow because the code base
                            is a mess</li>
                    </ul>

                    <div class="meta">
                        <p class="credits">by Martin Fowler</p>

                        <p class="date">29 Jan 2009</p>

                        <p class="more"><a href="/bliki/FlaccidScrum.html">Read more…</a></p>

                        <p class="type bliki">bliki</p>

                        <p class="tags"> <span class="tag-link"><a href="/tags/agile.html">agile</a></span> <span
                                class="tag-link"><a href="/tags/agile%20adoption.html">agile adoption</a></span> <span
                                class="tag-link"><a href="/tags/bad%20things.html">bad things</a></span> </p>
                    </div>
                </div>
            </div>

            <div class="article-card">
                <h3><a href="/bliki/FeatureDevotion.html">Feature Devotion</a></h3>

                <div class="card-body">
                    <p class="card-image"><img src=""></p>

                    <p>A common, perhaps dominant, practice of agile methods is to
                        develop a list of features (often called stories) for the software
                        that's being built. These features are tracked with index cards,
                        work queues, burndown charts, backlogs, or whatever your tool of
                        choice is.</p>

                    <div class="meta">
                        <p class="credits">by Martin Fowler</p>

                        <p class="date">2 Nov 2006</p>

                        <p class="more"><a href="/bliki/FeatureDevotion.html">Read more…</a></p>

                        <p class="type bliki">bliki</p>

                        <p class="tags"> <span class="tag-link"><a href="/tags/agile.html">agile</a></span> <span
                                class="tag-link"><a href="/tags/bad%20things.html">bad things</a></span> <span
                                class="tag-link"><a href="/tags/requirements%20analysis.html">requirements
                                    analysis</a></span> <span class="tag-link"><a
                                    href="/tags/process%20theory.html">process theory</a></span> </p>
                    </div>
                </div>
            </div>
        </section>
    </main>


    <!-- 第三部分 -->
    <nav id="bottom-navmenu" style="display: none;">
        <nav class="navmenu">
            <div class="nav-head">
                <div class="search">
                    <!-- SiteSearch Google -->
                    <form method="GET" action="https://www.google.com/search">
                        <input type="hidden" name="ie" value="UTF-8">
                        <input type="hidden" name="oe" value="UTF-8">
                        <input class="field" type="text" name="q" size="15" maxlength="255" value="">
                        <button class="button" type="submit" name="btnG" value=" " title="Search">
                            <input type="hidden" name="domains" value="martinfowler.com">
                            <input type="hidden" name="sitesearch" value="">
                            <input type="hidden" name="sitesearch" value="martinfowler.com">

                        </button>
                    </form>
                </div>

                <div class="closediv">
                    <span class="close" title="close"></span>
                </div>
            </div>

            <div class="nav-body">
                <div class="topics">
                    <h2>Topics</h2>

                    <p><a href="/architecture">Architecture</a></p>

                    <p><a href="https://refactoring.com">Refactoring</a></p>

                    <p><a href="/agile.html">Agile</a></p>

                    <p><a href="/delivery.html">Delivery</a></p>

                    <p><a href="/microservices">Microservices</a></p>

                    <p><a href="/data">Data</a></p>

                    <p><a href="/testing">Testing</a></p>

                    <p><a href="/dsl.html">DSL</a></p>
                </div>

                <div class="about">
                    <h2>about me</h2>

                    <p><a href="/aboutMe.html">About</a></p>

                    <p><a href="/books">Books</a></p>

                    <p><a href="/faq.html">FAQ</a></p>
                </div>

                <div class="content">
                    <h2>content</h2>

                    <p><a href="/videos.html">Videos</a></p>

                    <p><a href="/tags">Content Index</a></p>

                    <p><a href="/articles/eurogames">Board Games</a></p>

                    <p><a href="/photos">Photography</a></p>
                </div>

                <div class="tw">
                    <h2>ThoughtWorks</h2>

                    <p><a href="https://thoughtworks.com/insights">Insights</a></p>

                    <p><a href="https://thoughtworks.com/careers">Careers</a></p>

                    <p><a href="https://thoughtworks.com/products">Products</a></p>
                </div>

                <div class="feeds">
                    <h2>follow</h2>

                    <p><a href="https://www.twitter.com/martinfowler">Twitter</a></p>

                    <p><a href="/feed.atom">RSS</a></p>
                </div>
            </div>
        </nav>
    </nav>
    <!-- 脚部, 脚部导航 -->
    <footer id="page-footer">
        <div class="tw-logo">
            <a href="http://www.thoughtworks.com">
                <img src="https://martinfowler.com/tw-white-300.png">
            </a>
        </div>
        <div class="menu-button">
            <div class="icon-bars navmenu-button"></div>
        </div>
        <div class="copyright">
            <p>© Martin Fowler | <a href="http://www.thoughtworks.com/privacy-policy">Privacy Policy</a> | <a
                    href="/aboutMe.html#disclosures">Disclosures</a></p>
        </div>
    </footer>


    <script src="/collection/jquery-3.5.1.min.js" type="text/javascript"></script>
    <script src="/collection/martinfowler/mfcom.js" type="text/javascript"></script>
    <script type="text/javascript">encloseWhenSmall('.article-card', 'h3');</script>
</body>


</html>